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DETAILED ACTION 

1. Claims 1-15 and 17-61 are pending. Claims 25-36 and 55-61 have been withdrawn. 
Claims 1-15, 17-24, and 37-54 have been examined. 

Papers Submitted 

2. It is hereby acknowledged that the following papers have been received and placed of 
record in the file: IDS as received on 6/6/2008 and Amendment as received on 8/8/2008. 

Information Disclosure Statement 

3 . It is desirable to avoid the submission of long hsts of documents if it can be avoided. 
Clearly irrelevant and marginally pertinent cumulative information should be eliminated. If a 
long hst is submitted, those documents which have been specifically brought to applicant's 
attention and/or are known to be of most significance should be highlighted. See Penn Yan 
Boats, Inc. v. Sea Lark Boats, Inc., 359 F. Supp. 948, 175 USPQ 260 (S.D. Fla. 1972), aff d, 479 
F.2d 1338, 178 USPQ 577 (5*^ Cir. 1973), cert, denied, 414 U.S. 874 (1974). But cf Molins PLC 
V. Textron Inc., 48 F.3d 1172, 33 USPQ2d 1823 (Fed. Cir. 1995). See MPEP 2004. 

Applicant's duty of disclosure of material and information is not satisfied by presenting a 
patent examiner with "a mountain of largely irrelevant [material] from which he is presumed to 
have been able, with his expertise and with adequate time, to have found the critical [material]. 
It ignores the real world conditions under which examiners work." Rohm & Haas Co. v. Crystal 
Chemical Co., 722 F.2d 1556, 1573 [220 USPQ 289] (Fed. Cir. 1983), cert, denied, 469 U.S. 851 
(1984). (Emphasis in original). Applicant has a duty not just to disclose pertinent prior art 
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references but to make a disclosure in such way as not to "bury" it within other disclosures of 
less relevant prior art; See Golden Valley Microwave Foods Inc. v. Weaver Popcorn Co. Inc., 24 
USPQ2d 1801 (N.D. Ind. 1992); Molins PLC v. Textron Inc., 26 USPQ2d 1889, at 1899 (D.Del 
1992); Penn Yan Boats, Inc. v. Sea Lark Boats, Inc. et al., 175 USPQ 260, at 272 (S.D. Fl. 1972). 

The examiner is not afforded the time to thoroughly review each reference, given the 
number of references cited. By initialing each of the cited references on the accompanying 1449 
form(s), the examiner is merely acknowledging the submission of the cited references and 
indicating that only a cursory review was made of the cited references. 
4. Reference AHH has not been considered because the Patent No. does not match the 
Patentee's name listed on the IDS. The examiner has noted that the inventor of Patent No. 
5,916,307 is not Hill, but instead Piskiel et al. Consequently, it is not clear if applicant meant to 
cite a different document. 



Specification 

5. The amended title of the invention submitted by applicant on December 27, 2007, is not 
descriptive. A new title is required that is clearly indicative of the invention to which the claims 
are directed. The examiner asserts that many prior art systems exist which include "buffered 
data transfer". The examiner requests that applicant amend the title to include language directed 
towards the uniqueness of the claimed invention. MPEP 606.01 states that such an amendment 
"may result in slightly longer titles, but the loss in brevity of title will be more than offset by the 
gain in its informative value in indexing, classifying, searching, etc. If a satisfactory title is not 
supplied by the applicant, the examiner may, at the time of allowance, change the title by 
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examiner's amendment." Through the examiner doesn't have any recommendations at this 
moment in time, the examiner would like to give applicant every opportunity to submit an 
informative title. 



Claim Rejections - 35 USC § 112 

6. The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification sliall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

7. Claims 1-9 are rejected under 35 U.S.C. 1 12, first paragraph, as failing to comply with 
the written description requirement. The claim(s) contains subject matter which was not 
described in the specification in such a way as to reasonably convey to one skilled in the relevant 
art that the inventor(s), at the time the application was filed, had possession of the claimed 
invention. Specifically, applicant has amended claim 1 such that the processor loads the same 
portion of published data into first and second parallel buffers under control of first and second 
data-transfer objects, respectively. The examiner has been unable to find support in the original 
disclosure for such a concept. Applicant points to Figs.3-5 and paragraphs [67]-[72] and [83] of 
the specification, but these paragraphs appear to only include support for: 

• A single thread publishing data to multiple locations within the accelerator via 
multiple channels (page 21, lines 27-28). However, this does not provide 
support for the same data being loaded to multiple parallel buffers. 
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• An accelerator receiving data via a single channel and providing it to multiple 
locations within the accelerator (page 22, lines 4-5). However, this does not 
provide support for the same data being loaded to multiple parallel buffers. 

• Multiple threads subscribing to data from the same channel (page 22, lines 5-7). 
However, this does not provide support for the same data being loaded to 
multiple parallel buffers. 

• Multiple threads publishing data to the same location within the accelerator via 
the same channel, although the threads may publish data to the same accelerator 
location via respective channels (page 22, 7-10). However, this does not 
provide support for the same data being loaded to multiple parallel buffers. 

If the examiner is incorrect in his assertion that claim 1 includes new matter regarding the 
same published data being loaded into parallel buffers, applicant is respectftiUy requested to 
point out specific support for such a processor in the original disclosure. 

8. Claims 2-9 are rejected under 35 U.S.C 112, 1^* paragraph, for containing new matter, 
because they are dependent, either directly or indirectly, on a claim which includes new matter. 

Claim Rejections - 35 USC § 102 

9. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in pubUc use or on 
sale in this country, more than one year prior to the date of appUcation for patent in the United States. 
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10. Claims 10-12, 14-15, 17-18, 37, 39-43, 45, and 47-49 are rejected under 35 U.S.C. 102(b) 
as being anticipated by Dretzka et al, U.S. Patent No. 4,703,475 (herein referred to as Dretzka). 
Note that the same claims are rejected multiple times under different interpretations of Dretzka. 

1 1 . Referring to claim 10, Dretzka has taught a computing machine, comprising: 

a) a first buffer. See Fig. 6, buffer 220-4, for instance. 

b) a processor (Fig.l, component 21) coupled to the buffer and operable to: 

bl) execute first and second data-transfer objects and an application. Fig.4 sets forth at 
least some of the data-transfer objects executed by processor 21 . Looking at Fig.4 and 
Fig. 6, a first transfer object would be executed to load data into buffer 220-4 and a 
second object would be executed to unload data from buffer 220-4. At least some of the 
other fimctions performed by the processor (for instance, doing normal ALU operations) 
would be part of the application inherently executed by the processor. 
b2) generate data under control of the application. See Fig.6 and Figs. 8-15, and note that 
the application generates data using an input list. 

b3) retrieve the generated data from the application and load the retrieved data into the 
buffer under the control of the first data-transfer object. See Fig.6. After data is 

generated by the input list, the first object transfers it to the buffer (i.e., 220-4). 
b3) unload the data from the buffer under the control of the second data-transfer object. 
See Fig.6. Data is ultimately moved/unloaded from the buffer 220-4 and into buffer 210 
under control of the second object. 

b4) process the unloaded data under the control of the application. See Fig.4 and Fig.6. 
From the buffer 210, the processor will process the data using an application. 
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12. Referring to claim 11, Dretzka has taught the computing machine of claim 10 wherein the 
first and second data-transfer objects respectively comprise first and second instances of the 
same object code. See Fig.6 and note that, in general, the first object retrieves data from a 
previous stage (level 2.5 stage) and stores it in a next buffer 220-4. Likewise, the second object 
retrieves data fi-om a previous stage (level 3) and stores it in a next buffer 210. Hence, both of 
these objects comprise instances of general "retrieve-and-store" object code. 

13. Referring to claim 12, Dretzka has taught the computing machine of claim 10 wherein the 
processor further comprises: 

a) a processing unit operable to execute the application, generate the data, and process the 
unloaded data under the control of the application. Recall from the rejection of claim 10 (and 
from Fig.4) that the processor performs each of these claimed fimctions. They are inherently 
performed by a processing unit. 

b) a data-transfer handler operable to execute the first and second data-transfer objects, to 
retrieve the data from the application and load the data into the buffer under the control of the 
first data-transfer object, and to unload the data from the buffer under the confrol of the second 
data-fransfer object. Again, recall from the rejection of claim 10 that the claimed objects are 
executed. The unit which performs this execution is a data transfer handler. 

14. Referring to claim 14, Dretzka has taught the computing machine of claim 10 wherein the 
processor is further operable to: 

a) execute a queue object and a reader object. See Fig.4 and Fig.6. The queue object is the 
object which stores the more bit, which ultimately leads to the informing of level 4 that a 
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complete message has been received. The reader object is the object which detects the more bit 
so that further action can occur. 

b) store a queue value under the control of the queue object, the queue value reflecting the 
loading of the retrieved data into the first buffer. See Fig.4 and Fig.6. The queue object will 
store the "more" bit, which reflects the loading of the retrieved data into the buffer. This bit, 
when set in a certain manner, will allow for the informing of level 4 of a complete message. 

c) read the queue value under the control of the reader object. See Fig.4 and note that the more 
bit, when set to a certain level, will indicate the end of the message and that the message may be 
further transmitted and processed. The reader object will have to read this more bit. 

d) notify the second data-transfer object that the retrieved data occupies the buffer under the 
control of the reader object and in response to the queue value. When the "more" bit is set in the 
appropriate manner and noted by the reader object, the data may be transferred to the next-level 
buffer. See Fig.4 and Fig.6. 

e) unload the retrieved data from the buffer under the control of the second data-transfer object 
and in response to the notification. Again, in response to the notification, the data will be moved 
from level 3 buffer to level 4 buffer. See Fig.4 and Fig.6. 

15. Referring to claim 15, Dretzka has taught the computing machine of claim 10, further 

comprising: 

a) a second buffer. See Fig.6, component 210. 

b) wherein the processor is operable to execute a third data-transfer object, to unload the data 
from the first buffer into the second buffer under the control of the second data-transfer object, 
and to provide the data from the second buffer to the application under the control of the third 
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data-transfer object. See Fig.4 and Fig.6. Data is unloaded from buffer 220-4 to buffer 210 
under control of the second transfer object, and then moved from buffer 210 to the application in 
the processor under confrol of the third object. 

16. Referring to claim 17, Dretzka has taught the computing machine of claim 10 wherein: 

a) the first and second data-transfer objects respectively comprise first and second instances of 
the same object code. See Fig.6 and note that, in general, the first object retrieves data from a 
previous stage (level 2.5 stage) and stores it in a next buffer 220-4. Likewise, the second object 
retrieves data from a previous stage (level 3) and stores it in a next buffer 210. Hence, both of 
these objects comprise instances of general "retrieve-and-store" object code. 

b) the processor is operable to execute an object factory and to generate the object code under the 
confrol of the object factory. All processors execute programs. The program (object factory) 
will dictate when data needs to be fransmitted and received. That is, when the program calls for 
data to be received, the first and second object codes will be generated and invoked so that data 
may be received. 

17. Referring to claim 10, Dretzka has taught a computing machine (under a second 

interpretation), comprising: 

a) a first buffer. See Fig. 5, buffer 120-4, for instance. 

b) a processor (Fig.l, component 11) coupled to the buffer and operable to: 

bl) execute first and second data-fransfer objects and an application. Fig.3 sets forth at 
least some of the data-fransfer objects executed by processor 1 1 . Looking at Fig.3 and 
Fig.5, a first fransfer object would be executed to load data into buffer 120-4 and a 
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second object would be executed to unload data from buffer 120-4 and into buffer 130-4. 
At least some of the other functions performed by the processor (for instance, doing 
normal ALU operations) would be part of the application inherently executed by the 
processor. 

b2) generate data under control of the application. See the top of Fig.3 and note that the 
processor generates data as a result of apphcation execution. 

b3) retrieve the generated data from the application and load the retrieved data into the 
buffer under the control of the first data-transfer object. See Fig.5. After data is 
generated, it is ultimately stored in buffer 120-4 (in the example shown). 
b3) unload the data from the buffer under the control of the second data-transfer object. 
See Fig.5. Data is ultimately moved/unloaded from the buffer 120-4 and into buffer 130- 
4 under confrol of the second object. 

b4) process the unloaded data under the control of the application. See Fig.3 and note 
that the data, after being removed from buffer 120-4, is further processed by adding a 1- 
byte header to the data and then assigning the data to a physical link for fransmission. 
18. Referring to claim 11, Dretzka has taught the computing machine of claim 10 (under a 
second interpretation) wherein the first and second data-transfer objects respectively comprise 
first and second instances of the same object code. See Fig.5 and note that, in general, the first 
object retrieves data from a previous stage (level 4 stage) and stores it in a next buffer 120-4. 
Likewise, the second object retrieves data from a previous stage (level 3) and stores it in a next 
buffer 130-4. Hence, both of these objects comprise instances of general "retrieve-and-store" 
object code. 
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19. Referring to claim 12, Dretzka has taught the computing machine of claim 10 (under a 
second interpretation) wherein the processor further comprises: 

a) a processing unit operable to execute the application, generate the data, and process the 
unloaded data under the control of the application. Recall from the rejection of claim 10 (and 
from Fig. 3) that the processor performs each of these claimed fimctions. They are inherently 
performed by a processing unit. 

b) a data-transfer handler operable to execute the first and second data-transfer objects, to 
retrieve the data from the application and load the data into the buffer under the confrol of the 

first data-transfer object, and to unload the data from the buffer under the control of the second 
data-transfer object. Again, recall from the rejection of claim 10 that the claimed objects are 
executed. The unit which performs this execution is a data fransfer handler. 

20. Referring to claim 14, Dretzka has taught the computing machine of claim 10 (under a 

second interpretation) wherein the processor is further operable to: 

a) execute a queue object and a reader object. See Fig.3 and Fig.5. The queue object is the 
object which causes a "more" bit to be set for data from buffer 1 10. The reader object is the 
object which at least reads the "more" bit to cause further action to occur. 

b) store a queue value under the control of the queue object, the queue value reflecting the 
loading of the retrieved data into the first buffer. See Fig.3 and Fig.5. Values (both data and 
"more" bit) are written into the level 3 storage until the "more" bit is set low, which means 
loading of the data is done. 
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c) read the queue value under the control of the reader object. The "more" bit would not be set 
for no reason. It clearly serves a purpose, and it will be read. The object which reads it is the 
reader object. 

d) notify the second data-transfer object that the retrieved data occupies the buffer under the 

control of the reader object and in response to the queue value. When the "more" bit is set and 
noted by the reader object, the data may be transferred to the next level of buffers. See Fig.3 and 
Fig.5. 

e) unload the retrieved data from the buffer under the confrol of the second data-fransfer object 
and in response to the notification. Again, in response to the notification, the data will be moved 
from buffer 120-4 to buffer 130-4. 

21 . Referring to claim 15, Dretzka has taught the computing machine of claim 10 (under a 
second interpretation), fiirther comprising: 

a) a second buffer. See Fig.5, component 130-4. 

b) wherein the processor is operable to execute a third data-transfer object, to unload the data 
from the first buffer into the second buffer under the confrol of the second data-fransfer object, 
and to provide the data from the second buffer to the application under the confrol of the third 

data-transfer object. See Fig.3 and Fig.5. Data is unloaded from buffer 120-4 to buffer 130-4 
(second buffer) under control of the second transfer object, and then moved from buffer 130-4 to 
the interface under confrol of the third object. 

22. Referring to claim 17, Dretzka has taught the computing machine of claim 10 (under a 
second interpretation) wherein: 
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a) the first and second data-transfer objects respectively comprise first and second instances of 
the same object code. See Fig.5 and note that, in general, the first object retrieves data fi-om a 
previous stage (level 4 stage) and stores it in a next buffer 120-4. Likewise, the second object 
retrieves data from a previous stage (level 3) and stores it in a next buffer 130-4. Hence, both of 
these objects comprise instances of general "retrieve-and-store" object code. 

b) the processor is operable to execute an object factory and to generate the object code under the 
confrol of the object factory. All processors execute programs. The program (object factory) 
will dictate when data needs to be fransmitted and received. That is, when the program calls for 
data to be transmitted, the first and second object codes will be generated and invoked so that 
data may be transmitted. 

23. Referring to claim 18, Dretzka has taught the computing machine of claim 10 (under a 
second interpretation) wherein the processor is further operable to package the generated data 
into a message that includes a header and the data under the control of the second data-transfer 
object. See Fig.3 (at least the level 2.5 object code), and note that the second object adds a 
header to the generated data to form a 22-byte packet. 

24. Referring to claim 37, Dretzka has taught a method comprising: 

a) publishing with an application data that includes no information indicating a destination of the 
data. See the top of Fig.3 and note that the processor produces (publishes) data messages as a 
result of application execution. Note that, at the time of generation, no destination information is 
produced. 
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b) loading the published data into a first buffer with a first data-transfer object. See Fig.3 and 
Fig.5 and note that the published data may be written to buffer 120-4 under control of the first 
transfer object (the code which performs at least the loading). 

c) retrieving the published data from the buffer with a second data-fransfer object. See Fig.3, 

Fig.5, and column 8, line 66, to column 9, line 4. The published data is retrieved from the first 
buffer under the control of the second fransfer object (the code which performs at least the 
retrieving). 

d) generating a message header that includes a destination of the retrieved data. See Fig.3 and 
note the code performed at level 2.5. In this step, a message header including logical channel 
number destination is generated and attached to the data. 

e) generating a message that includes the retrieved data and the message header. See Fig.3 and 
note that a 22-byte message is produced from the 21 -byte data and 1-byte header. 

25. Referring to claim 39, Dretzka has taught the method of claim 37, further comprising: 

a) generating a queue value that corresponds to the presence of the published data in the buffer. 
See Fig.3 and note that when the last part of the message is found, it is indicated by generating a 
"more" bit (queue value). 

b) notifying the second data-transfer object that the published data occupies the buffer in 
response to the queue value. Note from Fig.3 that when the last packet is found and the more bit 
is set, the code which then retrieves the data must be notified. 

c) wherein retrieving the published data comprises retrieving the published data from the buffer 
with the second data-fransfer object in response to the notification. See Fig.3, and note the level 
2.5 code. 
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26. Referring to claim 40, Dretzka has taught the method of claim 37, further comprising 
driving the message onto a bus with a communication object. See Fig.3 and Fig.5. After being 
stored in the level 2.5 buffer, the message is driven on the bus with a communication object. 

27. Referring to claim 4 1 , Dretzka has taught the method of claim 37, further comprising 
loading the retrieved data into a second buffer with the second data-transfer object. See Fig.3 
and Fig.5 and note that after being stored in a first buffer 120-4, the second object retrieves the 
data and stores it in another buffer 130-4, for instance. 

28. Referring to claim 42, Dretzka has taught the method of claim 37 wherein generating the 

message header and the message comprise generating the message header and the message with 
the second data transfer object. See Fig.3, level 2.5 code, in which the header is generated and 
attached to the data. 

29. Referring to claim 43, Dretzka has taught the method of claim 37, further comprising: 

a) generating data-transfer object code with an object factory. All processors execute programs. 
The program (object factory) will dictate/generate when data needs to be transmitted and 
received. That is, when the program calls for data to be transmitted or received, the data transfer 
objects will be invoked so that data may be transmitted and received. Clearly, the hardware 
shown in the figures must have some software interaction because without software, the 
hardware would be useless. 

b) generating the first data-transfer object as a first instance of the object code. When data needs 
to be transferred, some type of "send" or "pass" or "store" conmiand must be generated. This 
command is part of the data transfer object. 



Application/Control Number: 1 0/684,053 Page 1 6 

Art Unit: 2183 

c) generating the second data-transfer object as a second instance of the object code. Similarly, 
when data needs to be transferred from first buffer to second buffer for header and message 
generation, some type of command needs to be generated. This command is part of the second 
data transfer object. 

30. Referring to claim 45, Dretzka has taught a method comprising: 

a) receiving a message that includes data and that includes a message header that indicates a 
destination of the data. See Fig.4 and Fig.6. Note that a message comes in with a 1-byte header 
(note level 2.5). 

b) loading into a first buffer with a first data-transfer object, the received data without the 
message header, the first buffer corresponding to the destination. See Fig.6 and note that the 
data is loaded into buffer 220-4 without the 1-byte message header (the 1-byte header is removed 
prior to storage in 220-4 according to Fig.4). The first buffer is located in a channel specified by 

the destination information sent with the message (see Fig. 3). 

c) unloading the data from the buffer with a second data-transfer object. See Fig.4 and Fig.6 and 
note that data is ultimately unloaded from buffer 220-4. 

d) processing the unloaded data with an application corresponding to the destination. See Fig.4 
and note that after the data is unloaded, it will be sent to the processor where inherent processing 

on that data will commence. 

3 1 . Referring to claim 47, Dretzka has taught the method of claim 45, further comprising: 
a) generating a queue value that corresponds to the presence of the data in the buffer. See Fig.4 
and Fig.6. The queue object will generates the "more" bit, which corresponds to the presence of 
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data in the buffer. This bit, when set in a certain manner, will allow for the informing of level 4 
of a complete message. 

b) notifying the second data-transfer object that the data occupies the buffer in response to the 
queue value. When the "more" bit is set in the appropriate manner and noted by the reader 
object, the data may be transferred to the next-level buffer by informing (notifying) the next level 
that data is ready to be transferred. See Fig.4 and Fig.6. 

c) wherein unloading the data comprises unloading the data from the buffer with the first data- 
transfer object in response to the notification. Again, in response to the notification, the data will 
be moved from level 3 buffer to level 4 buffer. See Fig.4 and Fig.6. 

32. Referring to claim 48, Dretzka has taught the method of claim 45, further comprising 
wherein receiving the message comprises receiving the message with the first data-fransfer 
object. See Fig.4 and Fig.6. Some code/object will cause the receiving of the data. That object 

is the first data transfer object. 

33. Referring to claim 49, has taught the method of claim 45, further comprising: 

a) receiving the message comprises retrieving the message from a bus with a communication 
object. See Fig.4 and Fig.6. Some code/object will cause the receiving of the data from a bus. 

That object is the communication object. 

b) transferring the data from the communication object to the first data transfer object. See Fig.4 
and Fig.6. Note that after the data is received, it is pass to the first data transfer object which at 
least stores it in buffer 220-4. 
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Claim Rejections - 35 USC § 103 

34. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the im ention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the stibject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

35. Claims 1-3 and 5-9 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Dretzka in view of Chamdani et al., U.S. Patent No. 6,985,975 (herein referred to as Chamdani). 

36. Referring to claim 1, Dretzka has taught a computing machine, comprising: 

a) first and second parallel buffers. See Fig.5, components 120-0 and 120-4, for instance. 

b) a processor (Fig.l, component 1 1) coupled to the buffers and operable to: 

bl) execute an application and first and third data-transfer objects. All processors 
inherently execute an application. And, Fig.3 sets forth the data-transfer objects executed 
by processor 1 1 . Looking at Fig.3 and Fig.5, a first transfer object would be executed to 
load data into buffer 120-0 and a third object would be executed to retrieve data fi-om 
buffer 120-0 for loading into buffer 130-0. 

b2) publish data under the control of the application. See the top of Fig.3 and note that 
the processor produces (publishes) data messages as a result of application execution. 
b3) load at least a portion of the published data into the first buffer under the control of 
the first data-transfer object. See Fig.3 and Fig.5 and note that the published data may be 
written to message buffers 120-0 under control of the first data transfer object. 
b4) retrieve at least the portion of the published data from the first buffer under the 
control of the third data-transfer object. See Fig.3, Fig.5, and column 8, line 66, to 
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coluron 9, line 4. The published data is retrieved from the first buffer under the control of 
the first transfer object. 

b5) Dretzka has not taught that the processor is operable to execute second and fourth 
data-transfer objects, load at least the same portion of the pubHshed data into the second 
buffer under control of the second data-transfer object, and retrieve at least the portion of 
the published data from the second buffer under the control of the fourth data transfer 
object. However, Chamdani has taught the concept of redundant fransfer of messages 
throughout a system. See the absfract, Fig.2, Fig.5, and claim 1. Essentially, a message 
is loaded into and retrieved from a first buffer. The same message is loaded into and 
retrieved from a second buffer. The messages from the first and second buffer are then 
compared to ensure that they are the same, thereby indicating that a reliable fransfer has 
occurred. Consequently, in order to implement reliable fransfer within Dretzka, it would 
have been obvious to one of ordinary skill in the art at the time of the invention to modify 
Dretzka such that the fransferring components of Dretzka are essentially replicated. That 
is, currently in Dretzka, first and third objects load and retrieve a message from a first 
buffer. Modifying Dretzka in view of Chamdani would result in also having second and 
fourth objects that load and retrieve the same message from a second buffer. These 
messages would then be compared to ensure reliability. 

37. Referring to claim 2, Dretzka in view of Chamdani has taught the computing machine of 

claim 1 wherein: 

a) the first and third data-fransfer objects respectively comprise first and second instances of first 
object code. See Fig.5 and note that, in general, the first object retrieves data from a previous 
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buffer 110 and stores it in a next buffer 120-0 in channel 0. Likewise, the third object retrieves 

data from a previous buffer 120-0 and stores it in a next buffer 130-0 in channel 0. Hence, both 

of these objects comprise instances of general "channel 0 retrieve-and-store" object code. 

b) the second and fourth data-transfer objects respectively comprise first and second instances of 

second object code. In Dretzka, as modified in view of Chamdani, the second object loads a 

redundant buffer. Likewise, the fourth object retrieves data from the redundant buffer. Hence, 

both of these objects comprise instances of general "redundant" object code. 

38. Referring to claim 3, Dretzka in view of Chamdani has taught the computing machine of 

claim 1 wherein the processor comprises: 

a) a processing unit operable to execute the apphcation and publish the data under the control of 
the application. Recall from the rejection of claim 1 (and from Fig.3) that the processor 
inherently executes an application and publishes data under confrol of the application. This 

execution and publishing is performed by a processing unit. 

b) a data-transfer handler operable to execute the first, second, third, and fourth data-transfer 
objects, to load the published data into the first and second buffers under the confrol of the first 
and second data-fransfer objects, respectively, and to retrieve the published data from the first 

and second buffers under the control of the third and fourth data-transfer objects, respectively. 
Again, recall from the rejection of claim 1 that first and second objects loading the first and 
redundant buffers, respectively, and third and fourth objects retrieve the data from first and 
redundant buffers, respectively. The unit which performs this execution for loading and 
retrieving data is a data fransfer handler. 
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39. Referring to claim 5, Dretzka in view of Chamdani has taught the computing machine of 
claim 1 wherein the processor is further operable to: 

a) execute a queue object and a reader object. See Fig.3 and Fig.5. The queue object is the 
object which causes data from buffer 1 10 to at least be broken up, attached to a header, and have 
a "more" bit set, before being stored in buffers in level 3. The reader object is the object which 
at least reads the "more" bit to cause further action to occur. 

b) store a queue value under the control of the queue object, the queue value reflecting the 
loading of the published data into the first buffer. See Fig.3 and Fig.5. Values are written into 
the level 3 storage until the "more" bit is set low, which means loading of the data is done. 

c) read the queue value under the control of the reader object. The "more" bit would not be set 
for no reason. It clearly serves a purpose, and it will be read. The object which reads it is the 
reader object. 

d) notify the third data-transfer object that the published data occupies the first buffer under the 
control of the reader object and in response to the queue value. When the "more" bit is set and 
noted by the reader object, the data may be transferred to the next level of buffers. See Fig.3 and 
Fig.5. 

e) retrieve the published data from the first buffer under the control of the third data-transfer 
object and in response to the notification. Again, in response to the third object, the data will be 
moved fi-om level 3 buffers to level 2.5 buffers. 

40. Referring to claim 6, Dretzka in view of Chamdani has taught the computing machine of 
claim 1, fiirther comprising: 

a) a bus. See Fig.2, at least components 40-4, 40-3, etc. 
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b) wherein the processor is operable to execute a communication object and to drive the data 
retrieved from one of the first and second buffers onto the bus under the control of the 
communication object. See Fig.2 and Fig.5. Note that after data is stored in a level 2.5 buffer 
(second buffers), a communication object will ultimately drive that data onto the bus via a digital 

facility interface (DFI) 14-0, 14-1, etc. 

4 1 . Referring to claim 7, Dretzka in view of Chamdani has taught the computing machine of 
claim 1, further comprising: 

a) a third buffer. See Fig.5, component 130-0, for instance. 

b) wherein the processor is operable to provide the data retrieved from one of the first and 
second buffers to the third buffer under the control of the respective one of the third and fourth 
data-transfer objects. Recall from Fig.5 that the first buffer is buffer 120-0 and that data will 
ultimately be moved from buffer 120-0 to buffer 130-0. The third object is the object which 

moves the data between these two buffers the first and third buffer. 

42. Referring to claim 8, Dretzka in view of Chamdani has taught the computing machine of 
claim 1 wherein the processor is fiirther operable to generate a message that includes a header 
and data retrieved from one of the first and second buffers under the control of the respective one 

of the third and fourth data-transfer objects. See Fig.3 (at least the level 2.5 object code), and 
note that the third object removes the data from buffers in level 3 and adds a header to the data to 
form a 22-byte packet. 

43. Referring to claim 9, Dretzka in view of Chamdani has taught the computing machine of 
claim 1 wherein: 
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a) the first and third data-transfer objects respectively comprise first and second instances of first 
object code. See Fig.5 and note that, in general, the first object retrieves data fi-om a previous 
buffer 1 10 and stores it in a next buffer 120-0 in channel 0. Likewise, the third object retrieves 
data fi-om a previous buffer 120-0 and stores it in a next buffer 130-0 in channel 0. Hence, both 
of these objects comprise instances of general "channel 0 retrieve-and-store" object code. 

b) the second and fourth data-transfer objects respectively comprise first and second instances of 
second object code. In Dretzka, as modified in view of Chamdani, the second object loads a 
redundant buffer. Likewise, the fourth object retrieves data from the redundant buffer. Hence, 
both of these objects comprise instances of general "redundanf object code. 

c) the processor is operable to execute an object factory and to generate the first object code and 
the second object code under the control of the object factory. All processors execute programs. 
The program (object factory) will dictate when data needs to be transmitted and received. That 
is, when the program calls for data to be transmitted, the first and second object codes will be 
generated and invoked so that data may be transmitted. 

44. Claim 4 is rejected under 35 U.S. C. 103(a) as being unpatentable over Dretzka in view of 
Chamdani, and further in view of the examiner's taking of Official Notice. 

45. Referring to claim 4, Dretzka in view of Chamdani has taught the computing machine of 
claim 1 . Dretzka has not taught that the processor is fiirther operable to execute a thread of the 
application and to publish the data under the control of the thread. However, Official Notice is 
taken that multithreaded processors and their advantages are well known and accepted in the art. 
Specifically, it is known to divide up a program into threads in order to increase efficiency by 
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reducing stall time. With multiple threads, the system may switch to a second thread when a first 
thread stalls, thereby hiding the stall time require by the first thread. Essentially, the processor is 
kept busy as often as possible with multithreading. As a result, in order to increase efficiency, it 
would have been obvious to one of ordinary skill in the art at the time of the invention to modify 
Dretzka such that the processor executes a thread of the application and publishes data under 
control of the thread. 

46. Claims 13, 38, 44, 46, and 50 are rejected under 35 U.S.C. 103(a) as being unpatentable 

over Dretzka in view of the examiner's taking of Official Notice. 

47. Referring to claim 13, Dretzka has taught the computing machine of claim 10 (under both 
the first and second interpretations of Dretzka). Dretzka has not taught that the processor is 
further operable to execute first and second threads of the appUcation, to generate the data under 
the control of the first thread, and to process the unloaded data under the control of the second 
thread. However, Official Notice is taken that multithreaded processors and their advantages are 
well known and accepted in the art. Specifically, it is known to divide up a program into threads 
in order to increase efficiency by reducing stall time. With multiple threads, since threads are 
independent sequences of instructions, the system may switch to a next thread when a first thread 
stalls, thereby hiding the stall time require by the first thread. Essentially, the processor is kept 
busy as often as possible with multithreading. As a result, in order to increase efficiency, and 
because generating data and processing unloaded data are independent tasks, it would have been 
obvious to one of ordinary skill in the art at the time of the invention to modify Dretzka such that 
the processor is operable to execute first and second threads of the application, to generate the 
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data under the control of the first thread, and to process the unloaded data under the control of 
the second thread. 

48. Referring to claim 38, Dretzka has taught the method of claim 37. Dretzka has not taught 
that pubhshing the data comprises publishing the data with a thread of the application. However, 
Official Notice is taken that multithreaded processors and their advantages are well known and 
accepted in the art. Specifically, it is known to divide up a program into threads in order to 
increase efficiency by reducing stall time. With multiple threads, since threads are independent 
sequences of instructions, the system may switch to a next thread when a first thread stalls, 
thereby hiding the stall time require by the first thread. Essentially, the processor is kept busy as 
often as possible with multithreading. As a result, in order to increase efficiency, it would have 
been obvious to one of ordinary skill in the art at the time of the invention to modify Dretzka 
such that publishing the data comprises publishing the data with a thread of the application. 

49. Referring to claim 44, Dretzka has taught the method of claim 37. Dretzka has further 
taught receiving the message and processing the data in the message with a processor (Fig. 4 and 
Fig.6). Dretzka has not explicitly taught the receiving processor is a pipeline accelerator. 
However, Official Notice is taken that pipelined processors and their advantages are well known 
and accepted in the art. A pipeline allows for the overlapping of execution, instead of serial 
execution, thereby speeding up the processor and increasing throughput. As a result, it would 
have been obvious to one of ordinary skill in the art at the time of the invention to modify 
Dretzka' s processor (Fig.l, component 21) such that it includes a pipeline for accelerating 
execution. 
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50. Referring to claim 46, Dretzka has taught the method of claim 45. Dretzka has not taught 
that processing the unloaded data comprises processing the unloaded data with a thread of the 
application corresponding to the destination. However, Official Notice is taken that 
multithreaded processors and their advantages are well known and accepted in the art. 
Specifically, it is known to divide up a program into threads in order to increase efficiency by 
reducing stall time. With multiple threads, the system may switch to a second thread when a first 
thread stalls, thereby hiding the stall time require by the first thread. Essentially, the processor is 
kept busy as often as possible with multithreading. As a result, in order to increase efficiency, it 
would have been obvious to one of ordinary skill in the art at the time of the invention to modify 
Dretzka such that the processor processes the unloaded data with a thread. 

5 1 . Referring to claim 50, Dretzka has taught the method of claim 45. Dretzka has not 
explicitly taught generating the message header and the message with a pipeline accelerator. 
However, Official Notice is taken that pipelined processors and their advantages are well known 
and accepted in the art. A pipeline allows for the overlapping of execution, instead of serial 
execution, thereby speeding up the processor and increasing throughput. As a result, it would 
have been obvious to one of ordinary skill in the art at the time of the invention to modify 
Dretzka's processor (Fig. 1, component 1 1) such that it includes a pipeline for accelerating 
execution. Note that in this series of rejections, processor 1 1 is the unit which generates the 
messages according to Fig.3. 



52. Claims 19-24 and 5 1-54 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Dretzka in view of Britton et al., U.S. Patent No. 6,216,191 (herein referred to as Britton). 
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53. Referring to claim 19, Dretzka has taught a peer-vector machine comprising: 

a) a buffer. See Fig.5, component 120-4. 

b) a bus. See Fig.2, components 40-0, 40-1, etc. 

c) a processor (Fig.l, components 11) coupled to the buffer and to the bus and operable to: 

cl) execute an application, first and second data-transfer objects, and a communication 
object. And, Fig.3 sets forth at least some of the data-transfer objects executed by 
processor 1 1 . Looking at Fig.3 and Fig.5, a first transfer object would be executed to 
load data into buffer 120-0, a second object would be executed to load data into buffer 
120-4, and third object would be executed to retrieve data from buffer 120-0 for loading 
into buffer 130-0, and a fourth object would be executed to retrieve data from buffer 120- 
4 for loading into buffer 130-4. At least some functions, other than those performed by 
the first and second objects, are performed by the contmiunication object. 
c2) publish data under the control of the application. See the top of Fig.3 and note that 
the processor produces (publishes) data messages as a result of application execution. 
c3) load the published data into the buffer under the control of the first data-transfer 
object. See Fig.3 and Fig.5 and note that the published data may be written to message 
buffers 120-4, etc. over time, under control of the first transfer object. 
c4) retrieve the published data from the buffer under the control of the second data- 
transfer object. See Fig.3, Fig.5, and column 8, line 66, to column 9, line 4. The 
published data is retrieved from the first buffer under the control of the second transfer 
object. 
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c5) construct a message under the control of the second data-transfer object, the message 
including the retrieved published data and information indicating a destination of the 
retrieved published data. See Fig.3 and note that a 1-byte header including destination 
information (channel number) is attached to the data, thereby forming a message to send 

to the receiver. 

c6) drive the published data onto the bus under the control of the communication object. 

See Fig.2 and Fig.5. Note that after data is stored in a level 2.5 buffer (second buffer), a 

conmiunication object will ultimately drive that data onto the bus via a digital facility 

interface (DPI) 14-0, 14-1, etc. 
d) a processor coupled to the bus, including the destination, and operable to receive the message 
from the bus, to recover the received published data from the message, to provide the recovered 
data to the destination, and to process the recovered data at the destination. See Fig. 1 and Figs.3- 
4. Note that the destination would specify "the other processor through channel LCN#" The 
circuitry of Fig.6 would receive the message , exfract the data, and then send it to the receiving 
processor, where it will be processed. 

Dretzka has not taught that the processor coupled to the bus is a pipeline accelerator 
coupled to the bus and that the recovered data is processed at the destination without executing a 
program instruction. However, Britton has taught the general concept of coupling a processor 
and an FPGA. See Fig. 1 . Consequently, the processor could communicate with the FPGA and 
access its user-defined circuitry, thereby accessing custom hardware for performing operations. 
Custom hardware is simply reactionary to data. No instruction is executed. As a result, it order 
to access custom circuitry for operation, it would have been obvious to one of ordinary skill in 
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the art at the time of the invention to modify Dretzka's processor 21 to be an FPGA. 
Furthermore, since pipelining is well known to be advantageous in the art, it would have been 
obvious to pipeline one or more of the processor and FPGA to increase throughput. 

54. Referring to claim 20, Dretzka in view of Britton has taught the peer vector machine of 
claim 19 wherein the destination includes a field-programmable gate array that is operable to 
process the recovered data. See Britton, Fig.l, component 104. 

55 . Referring to claim 2 1 , Dretzka in view of Britton has taught the peer vector machine of 
claim 19, further comprising 

a) a registry coupled to the processor and operable to store object data. The examiner asserts that 
the processor's objects are made up of instructions which must be stored somewhere so that the 
processor may access and execute them. The storage holding the instructions is the registry. 

b) wherein the processor is operable to execute an object factory, and to generate the first and 
second data-transfer objects and the communication object fi-om the object data under the control 
of the object factory. All processors execute programs. The program (object factory) will 
dictate when data needs to be transmitted and received. That is, when the program calls for data 
to be transmitted, the first and second object codes will be generated and invoked so that data 
may be transmitted. 

56. Referring to claim 22, Dretzka has taught a peer vector machine comprising: 

a) a buffer. See Fig.6, component 220-4, for instance. 

b) a bus. See Fig.2, component 40-1, 40-2, etc. 

c) a unit coupled to the bus and operable to generate data, to generate a header including 
information indicating a destination of the data, to package the data and header into a message. 
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and to drive the message onto the bus. See Fig.l, unit 11, and Fig.3 and Fig.5. Note that the unit 
generates data, and then a message including the data and a header (with destination data 
specifying "other processor via channel LCN#"), and then drives that data onto bud 40-0, 40-1, 
etc (Fig.2), through the digital facility interface. 

d) a processor (Fig.l, component 21) coupled to the buffer and to the bus and operable to: 

dl) execute an application, first and second data-transfer objects, and a communication 
object. Fig.4 sets forth at least some of the data-transfer objects executed by processor 
21 . Looking at Fig.4 and Fig.6, a first transfer object would be executed to load data into 
buffer 220-4 and a second object would be executed to unload data from buffer 220-4 and 
into buffer 210. The communication object would be executed to retrieve data from the 
DFI 14-0, 14-1, etc, and store it into one of buffers 230-4. At least some of the other 
functions performed by the processor (for instance, doing normal ALU operations) would 
be part of the application inherently executed by the processor. 

d2) receive the message from the bus iinder the control of the communication object. See 
Fig.4 and Fig.6. Note that a message is received from the interface under the control of 
the communication object. 

d3) load into the buffer under the control of the first data-transfer object the received data 
without the header, the buffer corresponding to the destination of the data. See Fig.4 and 
Fig.6 and note that before being stored in the first buffer in level 3, the 1-byte header is 
deleted. 
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d4) unload the data from the buffer under the control of the second data-transfer object. 
See Fig.4 and Fig.6 and note that from the first buffer, the data is moved to the buffer 210 
before ultimately being sent to the processor 21 . 

d5) process the unloaded data under the confrol of the application. See Fig.4 and Fig.6. 

From the buffer 210, the processor will process the data using an application, 
e) Dretzka has not taught that the unit coupled to the bus is a pipeline accelerator coupled to the 
bus and that the recovered data is processed at the destination without executing a program 
instruction. However, Britton has taught the general concept of coupling a processor and an 
FPGA. See Fig. 1 and note the bidirectional bus, meaning both the processor and FPGA can 
communicate data to each other. Consequently, the processor could communicate with the 
FPGA and access its user-defined circuitry, thereby accessing custom hardware for performing 
operations. Custom hardware is simply reactionary to data. No instruction is executed. As a 
result, it order to access custom circuitry for operation, it would have been obvious to one of 
ordinary skill in the art at the time of the invention to modify Dretzka's unit 1 1 to be an FPGA. 
Furthermore, since pipelining is well known to be advantageous in the art, it would have been 
obvious to pipeline one or more of the processor and FPGA to increase throughput. 
57. Referring to claim 23, Dretzka in view of Britton has taught the peer vector machine of 
claim 22 wherein the processor is operable to receive the message from the bus under the control 
of the communication object, and to recover the data from the message under the control of the 
first data-fransfer object. See Fig.4 and note that the communication object receives the message 
from the bus. And, the first data object recovers the data from the message. See at least the level 
3 code of Fig.4. 
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58. Referring to claim 24, Dretzka in view of Britton has taught the peer vector machine of 
claim 22, further comprising: 

a) a registry coupled to the processor and operable to store object data. The examiner asserts that 
the processor's objects are made up of instructions which must be stored somewhere so that the 
processor may access and execute them. The storage holding the instructions is the registry. 

b) wherein the processor is operable to execute an object factory, and to generate the first and 
second data-transfer objects and the communication object from the object data under the control 
of the object factory. All processors execute programs. The program (object factory) will 
dictate when data needs to be transmitted and received. That is, when the program calls for data 
to be received, the first and second object codes (and communication object codes) will be 
generated and invoked so that data may be received. 

59. Referring to claim 5 1 , Dretzka has taught a method comprising: 

a) publishing data with an application running on a processor. See the top of Fig.3 and note that 
the processor produces (publishes) data as a result of application execution. 

b) loading the published data into a buffer with a first data-fransfer object running on the 
processor. See Fig.3 and Fig.5 and note that the published data may be written to buffer 120-4 
under control of the first transfer object (the code which performs at least the loading). 

c) retrieving the published data from the buffer with a second data-transfer object running on the 
processor. See Fig.3, Fig.5, and column 8, line 66, to column 9, line 4. The published data is 
retrieved from the first buffer under the confrol of the second fransfer object (the code which 
performs at least the retrieving). 
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d) generating information that indicates a destination of the retrieved data. See Fig. 3 and note 
the code performed at level 2.5. In this step, a message header including logical channel number 
destination is generated and attached to the data. 

e) packaging the retrieved data and the information into a message. See Fig.3 and note that a 22- 

byte message is produced from the 21 -byte data and 1-byte header. 

f) driving the message onto a bus with a communication object running on the processor. See 
Fig.3 and Fig.5. After being stored in the level 2.5 buffer, the message is driven on the bus with 
a communication object. 

g) receiving the message from the bus and processing the published data with a unit. See Fig.4 
and Fig.6. Note that unit 20 of Fig. 1 receives the messages sent by unit 10. 

h) Dretzka has not taught that the unit is a pipeline accelerator that includes a field- 
programmable gate array. However, Britton has taught the general concept of coupling a 
processor and an FPGA. See Fig. 1 and note the bidirectional bus, meaning both the processor 
and FPGA can communicate data to each other. Consequently, the processor could 
communicate with the FPGA and access its user-defined circuitry, thereby accessing custom 
hardware for performing operations. Custom hardware is simply reactionary to data. No 
instruction is executed. As a result, it order to access custom circuitry for operation, it would 
have been obvious to one of ordinary skill in the art at the time of the invention to modify 
Dretzka's unit 20 (or at least 21) to be an FPGA. Furthermore, since pipelining is well known to 
be advantageous in the art, it would have been obvious to pipeline one or more of the processor 
and FPGA to increase throughput. 
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60. Referring to claim 52, Dretzka in view of Britton has taught a method as described in 
claim 51, further comprising: 

a) generating a message that includes a header and the published data with the second data- 
transfer object. See Fig.3 and note that in addition to receiving the data from the level 3 buffer, 
the second object also generates the header in the level 2.5 code of Fig.4. 

b) driving the data onto the bus comprises driving the message onto the bus with the 
communication object. See Fig.3 and Fig.5. After being stored in the level 2.5 buffer, the 
message is driven on the bus with a communication object. 

c) receiving and processing the published data comprises receiving the message and recovering 
the published data from the message with the pipeline accelerator. Again, see Fig.4 and Fig.6, 
and recall the modification in view of Britton. 

61 . Referring to claim 53, Dretzka has taught a method comprising: 

a) generating with a unit a message header that includes a destination of data. See Fig.3 and note 
the level 2.5 object which generates a 1-byte header including a logical channel destination. 

b) generating with the unit a message that includes a header and the data. See Fig.3 and note that 
in generating the 1-byte header, the unit forms a 22-byte message with 21 -bytes of data. 

c) driving the message onto a bus with the unit . See Fig.3 and Fig.5. Note that after the 
messages are generated, they are sent over the bus shown in Fig.2 using the digital facility 
interface (DFl). 

d) receiving the message from the bus with a communication object running on a processor. See 
Fig.4 and Fig.6. note that processor 21 of Fig. 1 is receiving the message using code shown in 
Fig.4. 
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e) loading into a buffer with a first data-transfer object running on the processor the received data 
absent the header, the buffer being identified by the destination. See Fig.4 and note the level 3 
object which stores data into the buffer in level 3 minus the header which was stripped in level 
2.5 of Fig.4. 

f) unloading the data from the buffer with a second data-transfer object running on the processor. 
See Fig.4 and Fig. 6 and note that data fi-om a buffer in level 3 is ultimately removed and moved 
on through the system. 

g) processing the unloaded data with an application running on the processor and identified by 
the destination. See Fig.4 and Fig.6. Eventually, the unloaded data makes its way to the 
processor for inherent processing. 

f) Dretzka has not taught that the unit is a pipeline accelerator. However, Britton has taught the 
general concept of coupling a processor and an FPGA. See Fig. 1 and note the bidirectional bus, 
meaning both the processor and FPGA can communicate data to each other. Consequently, the 
processor could communicate with the FPGA and access its user-defined circuitry, thereby 
accessing custom hardware for performing operations. Custom hardware is simply reactionary 
to data. No instruction is executed. As a result, it order to access custom circuitry for operation, 
it would have been obvious to one of ordinary skill in the art at the time of the invention to 
modify Dretzka's unit 10 (or at least 1 1) to be an FPGA. Furthermore, since pipelining is well 
known to be advantageous in the art, it would have been obvious to pipeline one or more of the 
processor and FPGA to increase throughput. 

62. Referring to claim 54, Dretzka in view of Britton has taught a method as described in 
claim 53, fiirther comprising recovering the data fi"om the message with the first data transfer 
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object. See Fig.4, and note that recovering the 
transfer object executing in level 2.5 of Fig.4. 
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from the message begins with the first data 



Response to Arguments 

63 . Applicant's arguments filed on August 8, 2008, have been fiilly considered but they are 

not persuasive. 

64. Applicant argues the novelty/rejection of claim 10 on page 26 of the remarks, in 
substance that: 

"Dretzka does not disclose a processor operable to generate data under the control of an 
application, load the data into a buffer, unload the data from the buffer, and process the unloaded 
data under the control of the application. Referring, e.g., to Dreztka's FIGS. 1 and 5, a processor 
1 1 arguably generates data under the control of an application, loads the data into a buffer 120, 
and unloads the data from the buffer. But Dreztka does not disclose that the processor 1 1 then 
processes the unloaded data under the control of the application; Dreztka discloses only that 
another processor 21 processes the unloaded data, arguably under the control of another 
application. A similar analysis applies to the processor 21 ." 

65. These arguments are not found persuasive for the following reasons: 

a) Regarding the examiner's first interpretation of claim 10, applicant points to Fig.5 in the 
argument, but the examiner has relied on Figs. 4 and 6 in the rejection. As stated in the rejection 
of claim 10, the processor (Fig.l, component 21): 

• executes first and second data-transfer objects and an application. Fig.4 sets forth 
at least some of the data-transfer objects executed by processor 21. Looking at 
Fig.4 and Fig. 6, a first transfer object would be executed to load data into buffer 
220-4 and a second object would be executed to unload data from buffer 220-4. 
At least some of the other functions performed by the processor (for instance. 
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doing normal ALU operations) would be part of the application inherently 
executed by the processor. 

• generates data under control of the application. See Fig. 6 and Figs.8-15, and note 
that the application generates data using an input list. 

• retrieves the generated data from the application and loads the retrieved data into 
the buffer under the control of the first data-transfer object. See Fig. 6. After data 
is generated by the input list, the first object transfers it to the buffer (i.e., 220-4). 

• unloads the data from the buffer under the confrol of the second data-fransfer 
object. See Fig. 6. Data is ultimately moved/unloaded from the buffer 220-4 and 
into buffer 210 under control of the second object. 

• processes the unloaded data under the confrol of the application. See Fig.4 and 
Fig.6. From the buffer 210, the processor will process the data using an 
application. 

b) Under the second interpretation of claim 10, in which the processor is component 1 1 in Fig.l, 
the data, after being removed from buffer 120-4, is further processed by adding a 1-byte header 
to the data and then assigning the data to a physical link for fransmission. See Fig.3. This is 
fiirther processing performed by the processor 1 1 . 

66. Applicant argues the novelty/rejection of claim 37 on page 27 of the remarks, in 
substance that: 

"Dretzka does not disclose publishing, with an application, data that includes no 
information indicating a destination of the data. Referring, e.g., to FIGS. 2 and 5 and col. 7, lines 
25-30, and col. 8, lines 51-58, Dretzka's processor 1 1 (arguably an application running on the 
processor) publishes a message that includes information (e.g., message sequence numbers) 
indicating a destination of the data. The processor 11 must including this destination information 
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with the message, because any available logical channel LCN may carry any message. That is, 
no logical channel LCN is associated with a predetermined destination. Therefore, if the 
processor 1 1 does not include destination information with the message, then the system will not 
know where to send the message." 

67. These arguments are not found persuasive for the following reasons: 

a) The data, when it is published before level 4 of Fig.3, does not include information indicating 

a destination. The destination information isn't added until the published data reaches level 2.5 

in Fig.3. In this step, a message header including logical channel number destination is 

generated and attached to the data. Note that, at the time of generation/publishing, no destination 

information is produced. 



68. Applicant argues the novelty/rejection of claim 45 on page 28 of the remarks, in 
substance that: 

"Dretzka does not disclose loading into a buffer received data without a message header, 
the buffer corresponding to a destination of the data. Referring, e.g., to FIGS. 5-6 and col. 8, line 
47 - col. 10, line 24, Dretzka loads the queues and buffers 110, 120, 130, 230, 220, and 210 only 
with received messages that each include a message header that indicates a destination of the 
data within the respective message. Furthermore, because Dretzka's logical channels LCN are 
selectable for any message based on availability, none of Dretzka's queues or buffers does or 
can correspond to a destination of the data with which it is loaded." 

69. These arguments are not found persuasive for the following reasons: 

a) The rejection clearly sets forth the examiner's interpretation of the claim in which a message 
with destination header is received, and before loading it into a first buffer, the destination data is 
removed from the header. See Fig.4, level 2.5. 



70. Applicant argues the novelty/rejection of claim 19 on page 30 of the remarks, in 
substance that: 
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"Furthermore, referring, e.g., to FIGS. 1-3, Britton does not disclose or suggest a pipeline 
accelerator that is operable to receive a message that includes information indicating a 
destination of data and to recover data from the message. Britton merely discloses an FPGAthat 
communicates with a processor 102 via a combined address and data bus AD or separate 
address and data busses A and D. 

Therefore, because Britton discloses an FPGA having an address-bus/data-bus interface 
and lacking a message-based interface as recited in claim 19, the Examiner has failed to make a 
prima facie showing of obviousness. 

Furthermore, because Dretzka discloses a message-based interface and Britton 
discloses an address-bus/data-bus interface, one of ordinary skill would not have been motivated 
to combine Dretzka and Britton to arrive at the subject matter recited in claim 19. 

And even if one were motivated to combine Dretzka and Britton, neither Dretzka nor 
Britton discloses or suggests how one would modify Britton's address-bus/data-bus interface to 
communicate with Dretzka's message-based interface." 

7 1 . These arguments are not found persuasive for the following reasons: 

a) The examiner asserts that Britton was relied on to show that an FPGA can process data sent by 

a processor. And, an FPGA include hardware capable of processing data without executing an 

instruction. Hence, the system of Dretzka would still hold in terms of sending and receiving 
messages, and recovering data from a message, but that data would be processed using an FPGA 
as opposed to software. 



72. The rejections for claims 22, 5 1 , and 53 are maintained for the same reasons set forth 
above in response to applicant's argimient with respect to claim 19. 



Conclusion 

73 . Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS fi-om the mailing date of this action. In the event a first reply is filed within TWO 
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MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to DAVID J. HUISMAN whose telephone number is (571)272- 
4168. The examiner can normally be reached on Monday-Friday (8:00-4:30). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Eddie Chan can be reached on (571) 272-4162. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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/David J. Huisman/ 

Primary Examiner, Art Unit 2183 

October 16, 2008 



